Spreadsheet Fields in Text

ABSTRACT

A system architecture integrates spreadsheet functionality into text. The architecture allows insertion of discrete individual fields, referred to as “free floating fields”, inline with normal textual sentences. In an HTML document, for example, the free floating fields are elements constructed along with text elements and rendered together as an integrated document. Once rendered, the free floating fields present contents that resemble normal text consistent with the surrounding text. The free floating fields offer spreadsheet functionality, including the ability to handle complex formulas, reference values in a separate free floating field or table, and automatically recalculate the formulas when a source value changes.

PRIORITY

This application is a continuation of and claims priority under 35U.S.C. §120 to U.S. application Ser. No. 10/961,313 filed Oct. 8, 2004,which is a continuation of and claims priority under 35 U.S.C. §120 toU.S. application Ser. No. 09/599,808 filed Jun. 21, 2000 and now U.S.Pat. No. 7,117,435, the disclosures of which are incorporated byreference herein in their entirety.

BACKGROUND

Word processing and spreadsheet programs are two well-known and widelyused software applications. Word processing programs permit users todraft letters, write books, and create other word-centric documents on acomputer. Word processing programs are typically designed with theauthor in mind by offering tools and user interfaces that make writingeasier, such as edit functions (e.g., cut, copy, paste, find, replace,etc.), spell and grammar checking, document formatting, and the like.Examples of word processing programs include “Word™” from MicrosoftCorporation and “WordPerfect™” from Corel Corporation.

Spreadsheet programs enable users to create financial records,accounting spreadsheets, budgets, and other number-centric documents ona computer. Spreadsheet programs are developed with the accountant inmind, focusing on tools and user interfaces that simplify data entry anddata manipulation. Spreadsheets typically offer such functionality asin-cell formulas, automatic recalculation as data changes, multi-sheetreferencing, cell formatting according to data type (e.g., dates,currency, percentages, etc.), and the like. One example of a spreadsheetprogram is the “Excel™” application from Microsoft Corporation.

In the beginning, spreadsheets and word processing texts were entirelyseparate from one another. There was essentially no integration.Computer users who wanted to create primarily word-based documents wouldselect a word processing program, while users who wished to producenumber-oriented documents turned to spreadsheet programs. Over time,however, word processing users expressed interest in incorporatingnumbers and a spreadsheet “look” into an otherwise word-dominateddocument.

To accommodate such crossover situations, word processing programsevolved to offer tables, a visual structure that could be used to holdand organize numbers and other types of data. Tables arrange data incolumns and rows, thereby emulating the spreadsheet “look”. Wordprocessing users can insert a table, modify its layout, and change cellformats to achieve a specific visual appearance to their data. Sometables even support rudimentary functions, such as adding a set ofcontiguous cells.

While visually similar to spreadsheets, word processing tables do notsupport full spreadsheet functionality. For instance, a user is not ableto insert functions into a table that automatically update anytime datais modified in the cells.

More recently, object-oriented programming and OLE technologies havebeen used to provide a richer integration experience. With OLE, wordprocessing users who want greater functionality can embed spreadsheetobjects into their word processing documents, instead of tables.Essentially, this is akin to embedding an “Excel™” spreadsheet (or otherspreadsheet program) into a document running on the “Word™” program (orother word processing program). The embedded object carries sufficientfunctionality to allow the user to enter formulas, format cells,recalculate functions, and do all of the things he/she would normally beable to do on a spreadsheet program.

Though the embedded spreadsheet visually resembles a table and providesthe desired spreadsheet functionality, it logistically remains aseparate program that must be invoked by the user. OLE requires thatboth types of application programs—a word processor and a spreadsheet—beinstalled on the computer. When the user wants to update the embeddedspreadsheet, the user invokes the spreadsheet object by moving a mousepointer to anywhere on the embedded object and double clicking the leftmouse button (or via some other actuation mechanism). In response, aninstance of the spreadsheet program is executed and the spreadsheetchanges appearance from a “table look” to a reduced size spreadsheetprogram with numbered rows and lettered columns and program specificmenus. In this state, the user can change functions, modify data,reformat the spreadsheet, and perform other spreadsheet tasks. When theuser is finished, the user returns focus to the word processing documentby moving the mouse pointer outside the spreadsheet object and singleclicking the left mouse button.

While the OLE approach offers the full spreadsheet functionality withina word processing document, the process is somewhat sophisticated andtypically performed by experienced users who are familiar with bothspreadsheets and word processing programs. For novice or lessexperienced users, it may be confusing to see a table and not appreciatethe difference between a word processing table and a full-functioningembedded spreadsheet object. From the user standpoint, differentoperations are used depending upon whether the visible structure is atable or a spreadsheet. Furthermore, common services such as textformatting, spell checking, and the like do not “tunnel” into theembedded OLE objects and thus, the user is forced to run such servicesfor both the document and the embedded spreadsheet.

Thus, even though the final appearance may be visually similar, wordprocessing tables and spreadsheets provide two completely separatemechanisms for displaying information.

A separate, but somewhat related problem, is that spreadsheetfunctionality has been traditionally limited to a grid. There has beenno integration of spreadsheet capabilities into word processing text.When writing a document containing both text and a spreadsheet, all dataand formulas are typically contained within the spreadsheet of thedocument. The text then references the values and formula results in thespreadsheet through sentences like, “The total cost of the project isidentified in Table 1”.

If the user actually wants to place a value or formula result in thetext, the user manually enters the values directly into the text. Forexample, the user might write, “The total cost of the project is $2,300,as identified in Table 1.” Unfortunately, the value (e.g., $2,300) isstatic text. If the user subsequently changes a value in thespreadsheet, thereby altering the total cost, the sentence remainsunchanged. The user must remember the sentence and update it manually.

Some word processing programs (e.g., Microsoft Word™) allow insertion of“fields” into text. Using fields, a user may enter dates, simpleequations, and the like. However, these fields are independentstructures that do not recalculate automatically as one would expect forrudimentary spreadsheet functionality. Moreover, these fields tend to bedifficult to edit.

Accordingly, there is a need to better integrate spreadsheetfunctionality into text.

With the rapidly growing popularity of the Internet, many documentsdelivered to and rendered on computers are written in markup languages,such as HTML (hypertext markup language). Markup languages can allowauthors to easily construct a desired visual layout of the document.Some HTML documents provide tables that look and function as if theywere integrated with the surrounding text. For instance, financialWebsites commonly offer informative discussions on retirement planning,college savings, or buying a house and include with those discussionsone or more tables that invite the user to fill in their personalfinancial information and goals. When the user finishes entering thedata fields, the document appears to make on-the-fly calculations andpresent the results together with the discussions.

Despite the appearance of in-document calculations, the HTML document isnothing more than an electronic form that receives data entered by theuser. When the user completes entry, the HTML document is submitted to aWeb server that extracts the user data and makes the appropriatefinancial calculations. The server places the results in another HTMLdocument and serves the document back to the user's computer. The submitand reply occur very quickly, so the user may be unaware that the HTMLdocument holding the results is different than the HTML document intowhich he/she initially entered data. In any event, the traditionalseparation between spreadsheets and text/tables has persisted into theWeb-based era.

SUMMARY

A system architecture integrates spreadsheet functionality into text andtables. The architecture allows insertion of discrete individual fields,referred to as “free floating fields”, inline with normal textualsentences. In an HTML document, for example, the free floating fieldsare HTML elements constructed along with text elements and renderedtogether as an integrated document. Once rendered, the free floatingfields present contents that resemble normal text.

The free floating fields offer spreadsheet functionality, including theability to handle complex formulas, reference values in a separate freefloating field or table, and automatically recalculate the formulas whena value changes. The values and formula results can also be formatted(e.g., numbers, date, times, currency, etc.), like a spreadsheet, whileremaining part of the normal text. The results of formulas and datavalues can also be formatted like normal text, using familiar textformatting tools.

Underlying the user interface, one implementation of the architectureseparates data handling functions from presentation functions. Thearchitecture includes a user interface manager to manage how the freefloating fields appear in a document (e.g., selection, cut, copy, paste,etc.) and to facilitate user entry of formulas and values into the freefloating fields. The architecture also has a spreadsheet functionalitymanager to manage the spreadsheet functions for the free floatingfields, such as recalculation, formula handling, referencing, and thelike.

The bifurcated architecture supports cross-referencing in which one freefloating field references text or data in another free floating field,even though the fields are separate from one another. As part of thecross-referencing, the architecture allows a user to reference otherfields using a reference edit operation (e.g., move pointer to the fieldand click to capture content in the field). The architecture furtheraccommodates automatic universal recalculation throughout all fields inthe document. Thus, when a user modifies the contents of one field, thearchitecture automatically recalculates any formulas in any freefloating fields affected by the modification.

The architecture also permits a user to reference textual content viafree floating fields. When entering a formula in a first free floatingfield, the user can select a range of normal text. A second freefloating field is automatically created around the range of text and areference to that second free floating field is automatically insertedinto the formula in the first free floating field. Upon confirmation,the formula is calculated to insert the referenced text into thesentence. As the text in the second free floating field is updated, theformula in the first field is automatically recalculated.

Many other architectural features and UI features are described.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary architecture for integratingspreadsheet functionality into word processing text and tables.

FIG. 2 illustrates a screen display of a rendered document having twofree floating fields and a single table that are capable of spreadsheetfunctionality. In FIG. 2, the free floating fields exhibit a normal“text look” and the table exhibits a “table look” during a non-editingmode.

FIG. 3 illustrates a screen display of the rendered document, where thefree floating fields exhibit a “cell look” and the table exhibits a“spreadsheet look” during an editing mode.

FIG. 4 illustrates a screen display of another rendered document, wherea free floating field references text in the document.

FIG. 5 illustrates a screen display of yet another rendered documenthaving multiple tables. In particular, FIG. 5 shows nested tables, whereone table is inserted into a cell of another table, and the ability toreference from one table to the other table.

FIG. 6 illustrates a screen display of another rendered document havingmultiple tables and a free floating field that appear in an edit mode.

FIG. 7 is a block diagram of an exemplary computer that implements thearchitectures of FIGS. 1 and 4.

FIG. 8 is a flow diagram of a process implemented by the architecture ofFIG. 1.

FIG. 9 is a diagrammatic illustration of how a user interface table in arendered document and underlying functional components in thearchitecture work together during a recalculation operation.

FIG. 10 is a diagrammatic illustration of how multiple free floatingfields and UI tables and underlying functional components in thearchitecture work together during a cross-table reference edit operationand a concurrent recalculation operation.

DETAILED DESCRIPTION

This disclosure describes an architecture that integrates spreadsheetfunctionality into word processing text. The architecture allowsinsertion of discrete individual fields, referred to as “free floatingfields”, inline with normal textual sentences. The free floating fieldsoffer spreadsheet functionality, including the ability to handle complexformulas, reference values in a separate free floating field or table,and automatically recalculate the formulas when a referenced valuechanges. The values and formula results can also be independentlyformatted (e.g., numbers, date, times, currency, etc.), like spreadsheetcells, while remaining part of the normal text of a document. Theresults of formulas and data values may also be formatted like normaltext, using familiar text formatting tools.

The architecture also supports integration of spreadsheet functionalityinto word processing tables. The tables resemble a spreadsheet whenbeing edited, and a table when not being edited. The tables enjoy thebenefits of word processing tables (e.g., size and shape formatting,spell and grammar checking, etc.) as well as the benefits ofspreadsheets (e.g., complex formulas, sorting, recalculation, etc.). Thearchitecture also allows cross referencing among tables and freefloating fields such that, when the content of one table cell or freefloating field is modified, the architecture automatically recalculatesany formulas in all tables and free floating fields that are affected bythe modification. With this architecture, spreadsheet functionality isno longer constrained to grids, but is available in customary text andacross table boundaries.

For discussion purposes, the architecture is described in the context ofcreating tables, text, and free floating fields in a document written ina markup language (e.g., HTML). In this manner, the user is afforded therich HTML formatting options of both text and tables, including tablelayout changes (e.g., merging and splitting cells), as well as thecalculation and formatting features specific to data that aretraditionally associated only with a separate spreadsheet application.However, it is noted that the architecture may be useful in otherdocument types that are not rooted in a markup language.

Architecture

FIG. 1 shows an exemplary architecture 100 that integrates spreadsheetfunctionality into word processing text. The architecture 100 may beimplemented on a standalone computer, a network server computer, anetwork client computer, or distributed at both the server and client.The architecture 100 includes a document renderer 102, one or more setsof table objects 104, one or more sets of spreadsheet objects 106, oneor more sets of free floating field objects 107, a spreadsheet editor108, a workbook 110, a spreadsheet engine 112, and one or more non-coreworksheet functions 114(1)-114(W) that may be optionally used by thespreadsheet engine 112.

The architecture 100 separates data handling functions from presentationfunctions of the integrated spreadsheet functionality. In this manner,the architecture may be characterized as a cooperation of two systemmanagers: a user interface (UI) manager 116 and a spreadsheetfunctionality manager 118. The UI manager 116 manages how the freefloating fields and tables appear in a document and facilitates suchtasks as table resizing, selection, cut, copy, paste, split, merge,table formatting and so on. The UI manager 116 includes the table object104, the spreadsheet objects 106, and the spreadsheet editor 108.

The spreadsheet functionality manager 118 manages the spreadsheetfunctions for the table and free floating fields, such as recalculation,formula handling, sorting, referencing, and the like. The spreadsheetfunctionality manager 118 includes the workbook 110, the spreadsheetengine 112 and worksheet functions 114. With the bifurcatedarchitecture, the spreadsheet functionality manager 118 is not concernedwith the table layout or other visual features, and the UI manager 116is not concerned with data management, formulas, and recalculationprocesses.

The bifurcated architecture 100 is advantageous in that it supportscross-referencing among the free floating fields and tables. It alsoallows reference editing during formula entry to allow convenientselection of other fields or cells and capturing of their contents asreferences used in the formula. The architecture further facilitatesautomatic universal recalculation of any formulas throughout all freefloating fields and tables in the document that are affected by usermodification of a single reference. These goals could also be achievedusing different, non-bifurcated architectures.

A document 120 is constructed and rendered on the document renderer 102.The document 120 combines a text-based body 122, one or more tables124(1) and 124(2), and one or more free floating fields (FFF) 126(1) and126(2). Each free floating fields 126 is akin to a single cell of atable that may be inserted anywhere in the document, including in themiddle of a text-based body.

For discussion purposes, the document 120 is written in a markuplanguage, such as XML (extensible markup language). XML documents can betransformed using XSL (extensible stylesheet language) and rendereddirectly as HTML (hypertext markup language). In this case, the renderer102 may be implemented as a browser or other application that handlesand renders HTML documents. The tables 124 are thus rendered as HTMLtables. Examples of various documents that contain integratedspreadsheet functionality into text are illustrated in FIGS. 2-6.

With continuing reference to FIG. 1, the table and spreadsheet objects104 and 106 provide editing functionality for the table 124, includingsuch functions as table resizing, selection, cut, copy, paste, split,merge, table formatting, and a host of other rich spreadsheet events.The free floating field objects 107 provide similar editingfunctionality for the free floating fields 126, with the exception thatcertain functions do not make sense in the context of a free floatingfield. For example, it does not make sense to “split” a free floatingfield as one would split a table cell.

The spreadsheet engine 112 provides the spreadsheet functionality forthe table 124 and free floating fields 126, including such functions asformula creation, reference editing, recalculation, and the like.Architecturally, the spreadsheet components are separate from the wordprocessing table and text, although the spreadsheet relies on the tableand free floating fields and the table and free floating fields providespecial notifications and events to help the spreadsheet. This allowseither component to add additional functionality without directlyaffecting the other component.

The spreadsheet engine 112 has a grid object for each table and freefloating field in the document 120, as represented by grid objects130(1) and 130(2). The grid objects 130 receives events indicative ofuser activity in the table 124 and free floating fields 126 andcoordinates actions among various objects. The workbook 110 initiallycreates the tables 124 and free floating fields 126, and subsequentlytracks all grid objects 130 to resolve any cross-table or free floatingfield referencing. Upon creation, a grid object 130 registers with theworkbook 110 so that it can participate when tables and free floatingfields are updated. The grid object 130 keeps an interface to thespreadsheet behavior 106 and the free floating field behavior 107 tofetch values from the HTML tree maintained at the renderer 102.

Each grid object 130 maintains two structures: a format table 132 and acell table 134. The format table 132 holds information about the dataformat of each cell in the table 124 or associated free floating field126. For instance, the cell or field may contain dates, numbers, dollaramounts, percentages, and so forth. In the example shown in FIG. 3, theformat table 132 would contain information that cells A1-A6, B1-B6, andC1, are text and cells C2-C6 are formatted as currency in U.S. dollars.Also in FIG. 3, the format table 132(2) for free floating field 126(1)contains information that the field is formatted as currency in U.S.dollars.

The cell table 134 stores the actual data for each cell in the table 124or an associated free floating field 126, such as text, values, andformulas. A cell table 134 stores pointers to one or more cells thatphysically store the data. A cell table associated with a table, such ascell table 134(1), contains multiple cells 136(1)-136(C), one for eachcell in the table. A cell table associated with a free floating field,such as field 134(2), contains only one cell 136 because the freefloating field 126(1) can be thought of as a table with only one cell.

Each cell 136 is an object containing the parsed value of the cell and areference to complete information about the cell. If the cell containstext or numeric data (e.g., cells A1-A6, B1-B5, and C1-C5 in FIG. 3), itis stored directly in the object. Formulas, such as the summationformula in cell C6 of FIG. 3, are stored as pointers to the appropriateformula object maintained by the formula manager 140 (discussed below).

The spreadsheet engine 112 includes a formula manager 140 to handle allformulas and parsing duties for formulas, data values, and references(e.g., D4:E23). The workbook 110 serves as the linkage between theformula manager 140 and the registered grids 130. The formula manager140 maintains a recalculation engine 142 that performs recalculation ofall formulas in response to event changes in the table or free floatingfields. In one implementation, the recalculation engine 142 maintainsthe formulas for a document in a bi-directional linked list, sometimesreferred to as the “formula chain”. Following a recalculation event(e.g., user entry of a new data value or new formula), the recalculationengine 142 traverses the list, evaluating formulas that may be affectedby the event.

If the current formula depends on other formulas that have not yet beenevaluated, the current formula is moved to the end of the list. Afterone recalculation pass, the formula list is organized in natural orderand will not need to be reordered during subsequent recalculationsunless new formulas are added. If recalculation comes to a formula thathas already been bumped to the end of the list and discovers that thisformula still relies on not-yet-calculated dependencies, the formulacontains a circular reference. In this case, the recalculation enginereturns a circular error.

The formula manager 140 also has a parser 144 that parses the formulas.In one implementation, the parser 144 is a recursive descent parser thatextracts tokens from a stream and appends them to an array ofcharacter-size operation types and a parallel array of variant operands.When done, the parser 144 creates a new formula object 146 and gives itthe two arrays of parsed information. The formula manager 140 thereforemaintains one or more formula objects 146(1)-146(B) that contain formulainformation, including the parsed formula expression returned by theparser 144, the current result, the type of formula, and the currentformula state.

In one implementation, there are three types of formulas: normal,semi-calculation, and non-calculation. The normal formula is reevaluatedonly when its dependencies change. The semi-calculation formula isreevaluated every time the recalculation engine 142 performs arecalculation operation. The non-calculation formula is never evaluatedat all. Non-calculation formulas are a special formula type for handlingnested tables (i.e., a table within a table) and nested free floatingfields.

Consider the case of an inner table nested inside a cell of an outertable. If the inner table contains a formula that changes to a differentvalue following recalculation, the value of the outer table will alsochange. Such a dependency is not encoded anywhere, since there is noformula attached to the outer table. In such cases, a non-calculationformula is set to re-fetch the resulting value from the innercalculation. Thus, it participates in the normal dependency managementof recalculation and all references to the outer table are updated whenappropriate.

In one implementation, the formula objects 146 are owned by a COMwrapper (not shown), which is in turn held onto by a cell object 136 inthe grid 130 where the formula resides. The formula objects 146 arethemselves part of the bi-directional linked list of formulas maintainedby the recalculation engine 142. The formula objects 146 containreferences to the table row and column (or the free floating field) theyare stored in and to the cell object 136 in grid 130. The referencesallow the recalculation engine 142 to travel down the recalculationchain with formulas from several tables and easily determine to whichtable a given formula belongs. Many operations, from formula saving totable deletion, depend on this ability to traverse the chain.

The formula manager 140 also parses referenced cell groups. As examples,the formula manager 140 parses “A5” as a cell reference, “D4:E23” as acompound rectangular reference, “$F$30” as an absolute reference,“Table5!D5” as a cross-table reference, “Field3” as a whole-tablecross-table reference, “A5:D5 B3:B6” as an intersection, and “D3,E4” asa union.

The non-core worksheet functions 114(1)-114(W) are optional elements.Examples of such functions include analysis functions, statisticalfunctions, and trigonometric functions. The modular architecture 100makes it flexible to remove unwanted worksheet functions or add newworksheet functions.

The spreadsheet objects 106 and free floating field objects 107 arecounterparts to their corresponding grid objects 130(1) and 130(2) andare located outside of the spreadsheet engine 112. There is one pair ofa spreadsheet object 106 and a grid object 130(1) per table 124 and onepair of corresponding free floating field behavior 107 and grid object130(2) per free floating field 126.

The spreadsheet objects 106 and free floating field objects 107 definebehaviors that receive events from the document renderer 102, processthem, and pass the events onto the corresponding grid objects 130(1) and130(2). In response to the events, the grid objects 130(1) and 130(2)update the cell data in cell tables 134(1) and 134(2) and/or formattinginformation in format tables 132(1) and 132(2).

The spreadsheet behavior 106 has three objects: GridBehavior 150,CellEditing 152, and Spreadsheet 154. The GridBehavior object 150provides a layer of abstraction between the grid object 130 andindividual HTML table cells and allows the grid object 130 to accessHTML values and styles. The GridBehavior object 150 wraps the HTMLelements in a common interface so that the grid 130 does not need toknow the particular structure of the HTML table. Additionally, theGridBehavior object 150 manages table-specific portions of a “referenceedit” operation.

The CellEditing object 152 and Spreadsheet object 154 interact directlywith an HTML tree and the table behavior 104 to provide the grid 130with events. The Spreadsheet object 154 is responsible for recordingundo records for actions affecting the spreadsheet.

The CellEditing object 152 manages user-level editing of cells. Itprocesses events related to user edits of in-cell data values andprovides some editing user interface (UI) elements, including theformula edit box that permits user edits of formulas. When editing aformula, a floating formula edit box is provided above the cell'slocation and resized as necessary to accommodate the formula. Thelocalized edit box eliminates a potential UI problem of forcing the userto fit the entire formula into the table cell, which may cause the tableto resize strangely as the user clicked into and out of the cell.

The CellEditing object 152 also supports the reference edit operationwhen the formula edit box is presented. As noted above, the referenceedit operation allows the user to visually reference cells using a mousepointer (or other focus mechanism) and in response, inserts a referenceto that cell data in the current formula edit box. The formula edit boxis described below in more detail. The CellEditing object 152 is onlypresent when a cell is being actively edited.

The free floating field behavior 107 has three objects: an FFFBehaviorobject 160, a CellEditing object 162, and a Spreadsheet object 164. TheCellEditing object 162 and Spreadsheet object 164 are essentiallyidentical to those in the spreadsheet behavior 106. For example, theCellEditing object 162 processes events related to user edits of freefloating fields and provides some editing user interface (UI) elements,including the formula edit box that facilitates user entry and editingof formulas. As with table cells, when editing a formula in a freefloating field, a floating formula edit box is provided above the freefloating field and resized as necessary to accommodate the formula.

The FFFBehavior object 160 takes the place of GridBehavior object 150and the Table object 104 in the context of free floating fields. Likethe Table object 104, the FFFBehavior object 160 monitors the documentfor changes to the free floating field, although these are much morelimited than in the case of a table. Like the GridBehavior object 150,the FFFBehavior object 160 provides an interface for the grid object130(2) and manages “reference edit” operations for the free floatingfield.

The spreadsheet editor 108 handles top-level duties such as inserting atable or a free floating field and routing commands to the appropriatetable based on the current selection in the document 120. The editor 108also creates and manages the workbook 110.

The integrated spreadsheet table and free floating field modeleliminates the need for the user to choose the structure of data withina document prior to creating that document. Historically, if the userneeded more control over the presentation of the tabular data, the usertended to select a word processing application. On the other hand, ifthe user required computations over the data, the user typically chose aspreadsheet application. The integrated architecture allows the user tocombine several different types of data within one document.

Additionally, by integrating spreadsheet functionality inside a tableand inline text fields, the user can build the document as they want. Inspreadsheet applications, the user is restricted to the grid layout forall document content. In the integrated architecture, users can create arich document that contains text integrated with multiple tables andmultiple free floating fields, each with data that can be formatted asvalues and used in calculations throughout different tables and fields.

Examples of Documents with Integrated Spreadsheet Functionality

FIG. 2 shows an example document 120 that has text body 122. In the FIG.2 example, the document 120 is a letter written to Mr. Jones describingvarious home improvement projects and the costs associated with theprojects. A single table 124 is situated in the text body. In thedepicted non-editing view, the table 124 resembles a standard wordprocessing table with three columns 202(1)-202(3) and five rows204(1)-204(5).

Two free floating fields 126(1) and 126(2) are inserted in the text body122 inline with the text. The free floating fields 126 appear as normaltext in the document 120. For instance, the second sentence recites,“The total cost of the project is $12,060”. The displayed value“$12,060” is a result of a formula in the underlying free floatingfield, which is currently hidden in this view. The formula sums theproject costs listed in the table 124.

FIG. 3 shows the same document 120 during editing, where the table 124and free floating fields 126(1) and 126(2) are shown as they would lookupon selection for editing. Notice that table 124 now “looks” like aspreadsheet more than a traditional table. The table 124 has integratedcolumn headers 302(1), 302(2), and 302(3), as well as integrated rowheaders 304(1)-304(6). The table 124 has a column expansion control 306and a row expansion control 308 to permit easy expansion of the table.

It is noted that FIG. 3 is merely an illustration for discussionpurposes. Typically, only one of the fields or the table is edited at atime, and hence that field or table exhibits the spreadsheet look (notall three as shown in FIG. 3). Thus, selecting the table for editinginvokes the column and row headers 302 and 304. Similarly, selecting afree floating field containing a formula would display the formula editbox. If, on the other hand, a free floating field does not contain aformula it will be selected in the same manner as all surrounding textis selected.

In this example, the user has added a row to the table and is entering asummation formula in cell C6 using a reference edit operation. With amouse pointer 310, the user references an array of cells C2 through C5for entry into the formula. Upon confirmation (e.g., releasing the leftmouse button), a reference to the cells C2 C5 are inserted into thesummation formula in cell C6 and after clicking out of the cell theformula is calculated to add the dollar amounts in column C. The resultof $12,060 is inserted into cell C6.

The free floating fields 126(1) and 126(2) contain formulas thatreference values and/or formulas located elsewhere in the document 120.The first free floating field 126(1) contains a formula that sums thedollar amounts in cells C2 C5 of the table 124, or“=SUM(Table1!C2:Table1!C5)”. The second free floating field 126(2)contains a formula that references both the first free floating field126(1) and a value in the table. Namely, the formula in the second freefloating field 126(2) computes the difference between the results of theformula in the first free floating field 126(1) and the cost of thekitchen repair in cell C3, or “=FFF1-Table1!C3”.

If a value in cells C2-C5 in the table 124 is modified, the freefloating fields 126(1) and 126(2) are automatically updated to reflectthe modification. For instance, suppose the user modifies the cost ofthe family room in cell C4 from $3,500 to $4,000. As a result of thischange, the formula in table cell C6 is automatically recalculated toyield $12,560, the formula in the first free floating field 126(1) isautomatically recalculated to yield $12,560, and the formula in thesecond free floating field 126(2) is automatically recalculated to yield$7,060.

FIG. 4 shows another example of a document 400 in which a free floatingfield 402 is used to reference text, rather than data values. In thiscase, free floating fields enable a new mechanism for the reference editoperation. As shown in FIG. 3, the typical reference edit operationallows entry of formula references into a spreadsheet by pointing at(i.e., clicking on) a referenced cell or range of cells while editingthe formula. The referenced cells are highlighted automatically and thecorrect reference to them is inserted into the formula. Free floatingfields extend the reference edit operation to allow a range of normaltext in a document to be referenced in a formula.

In contrast to this typical reference edit operation, the free floatingfield 402 in document 400 contains a formula that references a textrange 404. Using a mouse pointer 406, the user selects a range of normaltext 404 and the text is highlighted. A new free floating field isautomatically created around the range of text 404 and a reference tothat new free floating field, FFF1, is automatically inserted into theformula being edited within the formula edit box 408. In this example,the edited formula is in free floating field 402; however, in othercases, the formula may be in a table. Upon confirmation (e.g., pressingthe return key), the formula is calculated and the referenced text“Formal Bid” is inserted into the sentence as part of the normal contextflow.

If the referenced text 404 is modified, the free floating field 402 isautomatically updated to reflect the modification. For instance, supposethe user changes “Formal” to “Final”. As a result, the free floatingfield 402 is automatically recalculated to hold the words “Final Bid”.

FIG. 5 shows a document 500 that contains a first or outer table 502 anda second or inner table 504 nested within cell B3 of the outer table502. The ability to nest tables is one feature of this architecture thatconventional spreadsheet programs do not provide. FIG. 5 furtherillustrates a reference edit operation across table boundaries in whichthe inner table 504 is being referenced for insertion into a formula incell C3 of the outer table 502.

It is noted that the inner table 504 may be replaced by a free floatingfield, akin to a nested one cell table. Moreover, the outer table 502may be replaced by a free floating field. In this manner, one or morefree floating fields may be nested within one or more table cells, anentire table may be nested within a free floating field, and one or morefree floating fields may be nested within one or more other freefloating fields.

FIG. 6 shows a document 600 having three tables 602, 604, and 606, and afree floating field 608. Document 600 illustrates a situation wheremultiple tables and fields can cross-reference one another.

The many features of the user interface presented through the variousrendered documents are discussed in greater detail below under thesection heading “User Interface Features”.

Exemplary Computing Environment

FIG. 7 illustrates an example of an independent computing device 700that can be used to implement the architecture of FIG. 1. The computingdevice 700 may be implemented in many different ways, including ageneral-purpose computer (e.g., workstation, server, desktop computer,laptop computer, etc.), a handheld computing device (e.g., PDA, PIM,etc.), a portable communication device (e.g., cellular phone withcomputing capabilities), or other types of specialized appliances (e.g.,set-top box, game console, etc.).

In the illustrated example, computing device 700 includes one or moreprocessors or processing units 702, a system memory 704, and a bus 706that couples the various system components including the system memory704 to processors 702. The bus 706 represents one or more types of busstructures, including a memory bus or memory controller, a peripheralbus, an accelerated graphics port, and a processor or local bus usingany of a variety of bus architectures. The system memory 704 includesread only memory (ROM) 708 and random access memory (RAM) 710. A basicinput/output system (BIOS) 712, containing the basic routines that helpto transfer information between elements within the computing device 700is stored in ROM 708.

Computing device 700 further includes a hard drive 714 for reading fromand writing to one or more hard disks (not shown). Some computingdevices can include a magnetic disk drive 716 for reading from andwriting to a removable magnetic disk 718, and an optical disk drive 720for reading from or writing to a removable optical disk 722 such as a CDROM or other optical media. The hard drive 714, magnetic disk drive 716,and optical disk drive 720 are connected to the bus 706 by a hard diskdrive interface 724, a magnetic disk drive interface 726, and a opticaldrive interface 728, respectively. Alternatively, the hard drive 714,magnetic disk drive 716, and optical disk drive 720 can be connected tothe bus 706 by a SCSI interface (not shown). It should be appreciatedthat other types of computer-readable media, such as magnetic cassettes,flash memory cards, digital video disks, random access memories (RAMs),read only memories (ROMs), and the like, may also or alternatively beused in the exemplary operating environment.

A number of program modules may be stored on ROM 708, RAM 710, the harddisk 714, magnetic disk 718, or optical disk 722, including an operatingsystem 730, one or more application programs 732, other program modules734, and program data 736. As one example, the architecture 100 may beimplemented as one or more programs 732 or program modules 734 that arestored in memory and executed by processing unit 702. The drives andtheir associated computer-readable media provide nonvolatile storage ofcomputer-readable instructions, data structures, program modules andother data for computing device 700.

In some computing devices 700, a user might enter commands andinformation through input devices such as a keyboard 738 and a pointingdevice 740. Other input devices (not shown) may include a microphone,joystick, game pad, satellite dish, scanner, or the like. In someinstances, however, a computing device might not have these types ofinput devices. These and other input devices are connected to theprocessing unit 702 through an interface 742 (e.g., USB port) that iscoupled to the bus 706. In some computing devices 700, a display 744(e.g., monitor, LCD) might also be connected to the bus 706 via aninterface, such as a video adapter 746. Some devices, however, do nothave these types of display devices. Computing devices 700 might furtherinclude other peripheral output devices (not shown) such as speakers andprinters.

Generally, the data processors of computing device 700 are programmed bymeans of instructions stored at different times in the variouscomputer-readable storage media of the computer. Programs and operatingsystems are typically distributed, for example, on floppy disks orCD-ROMs. From there, they are installed or loaded into the secondarymemory of a computing device 700. At execution, they are loaded at leastpartially into the computing device's primary electronic memory. Thecomputing devices described herein include these and other various typesof computer-readable storage media when such media contain instructionsor programs for implementing the steps described below in conjunctionwith a microprocessor or other data processor. The service system alsoincludes the computing device itself when programmed according to themethods and techniques described below.

For purposes of illustration, programs and other executable programcomponents such as the operating system are illustrated herein asdiscrete blocks, although it is recognized that such programs andcomponents reside at various times in different storage components ofthe computing device 700, and are executed by the data processor(s) ofthe computer.

It is noted that the computer 700 may be connected to a network via awire-based or wireless connection to interact with one or more remotecomputers. In this network context, the computer 700 may be configuredto store and execute portions of the architecture 100, while one or moreremote computers store and execute other portions of the architecture.For example, the document renderer 102 may reside on one computer, whilethe remaining components reside on a separate computer. As a result, thearchitecture is distributed, with various components being stored ondifferent computer-readable media.

General Operation

FIG. 8 shows a table/spreadsheet process 800 implemented by thearchitecture 100 of FIG. 1. The process 800 may be embodied in softwarestored and executed on a computer, such as computing device 700 in FIG.7. Accordingly, the process 800 may be implemented ascomputer-executable instructions that, when executed on a processingsystem such as processor unit 702, perform the operations and tasksillustrated as blocks in FIG. 8.

At block 802, the architecture 100 creates a corresponding pair of freefloating field and grid objects 107 and 130 for a new free floatingfield presented as part of the document. In one implementation, theFFFBehavior object 160, CellEditing object 162, and Spreadsheet object164 are initially created for the new free floating field and then theSpreadsheet object 164 creates an associated grid object 130(2) in thespreadsheet engine 112. The grid object 130(2) includes a format table132(2) and a cell table 134(2). If this is the first spreadsheet, aworkbook 110 is also created. The grid 130 and workbook 110 then createother objects, including the formula manager 140 and a cell object 136.

At block 804, in response to the user entering data and/or formulas intothe free floating field, the architecture receives the user entry andpasses it to the spreadsheet engine 112 for processing. Morespecifically, in the continuing exemplary implementation, theSpreadsheet object 164 receives a notification from the documentrenderer 102 and passes it along to the grid 130(2) for the new freefloating field.

At block 806, based on the user input, the architecture determineswhether to parse the user-entered information or delay parsing untillater. The architecture preferably employs a delay parser that parsesfields and table cells when necessary, such as the first time that aformula has been loaded or the first time a value has been edited orreferenced. If the field contains a formula, the cell is parsedimmediately and added to the recalculation chain. If the field does notcontain a formula, it is left unparsed until a formula requires itsvalue.

At block 808, assuming that parsing is needed now (i.e., the “no” branchfrom block 806), the architecture parses the user-entered informationand updates the format table 132 and cell table 134 based upon thisinformation. At block 810, the architecture determines whetherrecalculation is appropriate. Some user input may not requirerecalculation, such as insertion of a new data value that is notreferenced by a formula. If recalculation is not needed, flow continuesat block 814 to determine whether the fields need to be updated as aresult of the user input.

At block 812, assuming recalculation is appropriate (i.e., the “yes”branch from block 810), the architecture recalculates the variousformulas that may have been affected by the user input. In the ongoingexample, the act of putting a value into a cell 136 in the cell table134 triggers a data-changed notification to registered listeners, whichincludes the grid objects 130(1) and 130(2). The grid objects identifyany changed cells and forward the notification to the formula manager140, which marks any formulas depending on the changed cells as dirtyand in need of recalculation.

The grid objects 130 then call the recalculation engine 142, which loopsover the recalculation formula chain and recomputes the variouslyaffected formulas (block 812(1)). While evaluating the formulas in theformula chain, unparsed cells that were previously left unparsed may nowbe parsed (block 812(2)).

Once the recalculation engine 142 finishes, it returns control to theworkbook 110. The workbook 110 calls back to the recalculation engine142 to learn which formulas changed as a result of the recalculationcycle. The workbook 110 then locates the grid objects 130 that hold theformulas and calls them to save the cells that contain the formulas.

At block 814, the architecture 100 determines whether any results havechanged following the recalculation. If results have not changed (i.e.,the “no” branch from block 814), process flow continues at block 804 forthe next user input. Conversely, if the results have changed (i.e., the“yes” branch from block 814), the architecture 100 loads an updated freefloating field with the modified value and renders the updated freefloating field as part of the document (block 816).

It is noted that the above example assumed that the user entered data ora formula. The user may also change the format of the free floatingfield. The process 800 handles format changes in essentially the sameway, but accounts for those changes in the format table 132(2) ratherthan the cell table 134(2).

User Interface Features

The architecture 100 supports many user interface (UI) features in therendered document to convey integration of spreadsheet functionalityinto word processing tables and text. These UI features are describedseparately below, with reference to FIGS. 2-6. Hand-in-hand with thesefeatures are the underlying operations and inner workings of variouscomponents in the architecture 100. These aspects will be described inmore detail later in this disclosure under the heading “FunctionalityFeatures”.

One of the primary benefits of integrating spreadsheet functionalityinto text and tables is that the user need no longer think in terms ofwhether the document should be primarily a spreadsheet document producedby a spreadsheet application (e.g., an “.xls” file from the “Excel™”program) or primarily a word processing document produced by a wordprocessing application (e.g., a “.doc” file from the “Word™” program).Instead, the user creates an HTML document (or other markup-baseddocument, such as an XML document) that can have both text andspreadsheet/table components. By integrating spreadsheet functionalityinto text, the user can build the document with automatically updateablefields without being restricted to the grid layout.

Integrated Headers

The table 124 toggles between a “table look” (FIG. 2) and a “spreadsheetlook” (FIG. 3) depending upon whether the user is editing the table. Thespreadsheet look may be invoked in a number of ways, including byactively editing a cell, by hovering a pointer over the table, or bysome other activity. As illustrated in FIG. 3, the spreadsheet lookincludes column headers 302(1)-302(3) and row headers 304(1)-304(6) thatintegrate with the table columns and rows, respectively. Visually, thecolumn headers 302 appear just above the columns and are labeled withletters A, B, C, etc., where as the row headers 304 reside to the leftof the rows and are labeled with numbers 1, 2, 3, etc.

Smart Selection

When the user selects text inside or outside a table, the architectureintelligently discerns the type of content in the cell or free floatingfield. For instance, the architecture determines whether the cell orfree floating field contains a data value, text, or a formula. If theselected cell or free floating field contains text or a value, the UIexhibits the selection as a character-based cursor ready for cellediting. If the selected cell or free floating field contains a formula,the UI exhibits the selection by highlighting the entire result of theformula. A second selection gesture will allow the user to edit theformula within the formula edit box.

Key Processing

Certain keys have different interpretations depending upon the contentsof the cell. This dynamic interpretation accommodates the competinginterests of a word processing table and a spreadsheet. As an example,the “Enter” key typically means return in word processing, whereas itmeans move to the next cell and commit the formula in a spreadsheetprogram.

If the cell contains text (e.g., cells A1-A6, B1-B5, and C1 in FIG. 3),the architecture interprets this cell as primarily being a wordprocessing-based cell and treats the keys as if the user were workingwithin a word processing application. Thus, an “Enter” key means return,a “tab” key means tab over some distance, the “=” key is typed inanywhere but the beginning of the cell as the equals symbol withoutdenoting a formula, and so forth. The same behavior is applied when theuser is editing text within a paragraph or a free floating field.

If the cell or free floating field contains a formula or a data value(e.g., cells C2-C6 and FFF1 in FIG. 3), the architecture interprets thiscell as primarily being a spreadsheet-based cell and treats the keys asif the user were working within a spreadsheet application. Thus, an“Enter” key and “tab” key mean navigation commands to move to the nextcell or move outside the free floating field, the “=” key at thebeginning of a cell implies the start of a formula, and so forth.

Table Expansion

Spreadsheet users are accustomed to the look and feel of an infinitegrid. While the spreadsheet look of FIG. 3 does not have the sameinfinite grid feel, the table 124 has a column expansion control 306 anda row expansion control 308 that allow easy addition of columns androws, respectively. The controls 306 and 308 include an actuatableaddition icon together with a dashed column/row to suggest thatadditional columns and rows may be added by simply actuating the icon.

Resize Behavior

The table 124 preserves column width and wraps text as the user enterssentences and phrases. In FIG. 3, notice that item 2 in cell B5 wrapswithin the cell, rather than resizing the column width to accommodatethe entire item.

Formula Edit Box

The architecture provides a formula edit box for inserting or editing aformula in a table cell or free floating field. The formula edit boxoverlays the original cell or free floating field in which the formularesides and initially defaults to the size and shape of the cell orunderlying text. If the formula exceeds the initial size, the formulaedit box is resized to accommodate the formula. During resizing, theformula edit box initially grows horizontally in length, and thenvertically in depth. The underlying table or paragraph does not resize.The ability to resize the local formula edit box, rather than the celland the table or the paragraph, eliminates a potential UI problem ofwatching the table or paragraph resize strangely as the user clicks intoand out of the cell containing the formula.

Examples of the formula edit box are illustrated in FIGS. 3, 4, 5 and 6.In FIG. 3, a formula edit box 312 hovers over cell C6 to accept thesummation formula. Additionally, formula edit boxes appear over 126(1)and 126(2). In FIG. 4, a formula edit box 408 appears for formula 402.In FIG. 5, a formula edit box 506 floats above cell C3 and is resized toaccommodate the expanded formula. Notice that the underlying table cellC3 and the table as a whole is not resized. In FIG. 6, a formula editbox 610 resides above the free floating field 608 and is resized to holdthe long formula.

Reference Edit

The table 124 and free floating field 126 allow the user to perform areference edit operation, in which the user references one or more cellsto extract their data values for inclusion in a formula in another cellor free floating field. In FIG. 3, the user begins entering a summationformula (i.e., “=SUM”) in the formula edit box 312 above cell C6. Theuser then references cells C2 through C5 using a pointer 310 or someother mechanism. The referenced cells C2:C5 are highlighted or otherwiseindicated as being selected, as represented by the bold rectangular boxaround the cells.

When the user finishes selecting the desired cells (e.g., releasing theleft mouse button after highlighting cells C2:C5), references to thecells are added to the summation formula in formula edit bock 312 (i.e.,“=SUM(C2:C5)”). Upon further confirmation by the user (e.g., pressingthe “Enter” key), an update event is generated and the architecture 100recalculates the formula and updates the cell C6 to display the sum ofthe cells C2:C5, or $12,060, in cell C6.

Reference Edit for Text

Free floating fields provide a unique mechanism for creating referencesto text via a reference edit operation. In FIG. 4, the user beginsentering a formula (i.e., “=”) into a formula edit box 408 overlaying afree floating field 402. The user then references the text 404 using apointer 406 or some other mechanism. The referenced text string ishighlighted or otherwise indicated as being selected and a second freefloating field is automatically formed around the text range 404.

When the user finishes selecting the text range (e.g., releasing theleft mouse button after highlighting text 404), a reference to the newlycreated free floating field is added to the formula in formula edit box408 (i.e., “=FFF1”). Upon further confirmation by the user (e.g.,pressing the “Enter” key), an update event is generated and thearchitecture 100 recalculates the formula and updates the free floatingfield 402 to display the text “Formal Bid”. It is noted that thereference could be made to text within a table cell, to text outside thetable or to text inside the table elsewhere in the cell or in anothercell.

Cross-Table Referencing and Universal Recalculation

The architecture 100 supports cross-table and cross-field referenceswhere a cell in one table or field contains a formula referencing a cellin another table. The architecture 100 also supports cross-table andcross-field reference edit operations that permit a user to reference acell in one table or a free floating field when entering a formula intoanother table.

FIG. 6 illustrates cross-table referencing, where table 606 containsreferences to tables 602 and 604. All three tables are separate andindependent from one another, and architecturally have their own set ofgrid, spreadsheet and table objects 130, 106, and 104. In FIG. 6, cellB2 in table 606 contains a summation formula for adding values in cellsB2 and B3 of table 602 (i.e., =SUM(Table1!B2:Table1!B3)). Cell B3 intable 606 contains a summation formula for adding values in cells B2through B4 in table 604 (i.e., =SUM(Table2!B2:Table2!B4)).

The ability to cross-reference other tables or free floating fields isbeneficial in that all tables and free floating fields can beuniversally updated for any change in just one of the tables. Forexample, suppose the user changes the value in cell B2 of table 602 from$300 to $400. As a result of this change, table 602 is updated toreflect the new value $400 and the total amount in cell B6 is updatedfrom $3,060 to $3,160. Additionally, the value in cell B2 of table 606is updated to $2,400, causing the total amount in cell B4 in table 606to be changed from $7,800 to $7,900.

The cross-table referencing is a significant improvement overconventional OLE techniques of embedding a spreadsheet object within aword processing document. With OLE, each spreadsheet object isindependent from each other and cannot reference cells in one anotherautomatically. Since there is no cross-referencing ability, the OLEapproach cannot support universal updating throughout the document'sspreadsheets as a result of changing a value in one spreadsheet.

Free Floating Field Reference Edit

The reference edit operation and cross-referencing is also availablewhen entering a formula for a free floating field. Consider the document600 in FIG. 6. The writer is attempting to summarize the total cost ofall work items in the opening paragraph. Rather than typing in a hardvalue, the user decides to insert a free floating field 608 that willhold the total for the job. By using a free floating field 608, theamount can be automatically updated as other estimates in the underlyingtables are modified.

Using a reference edit operation, the user can enter the formula in theedit box 610 for free floating field 608 by selecting cell B6 in table602 to capture element “Table1!B6” and then selecting cell B8 in table604 to capture element “Table2!B8”. When the user confirms this formula,the formula edit box 610 disappears and the total value of “$12,060” isinserted into the free floating field 608.

In the event the user subsequently changes the estimate of any item intables 602 or 604, the total value in free floating field 608 isautomatically updated. Extending a previous example, suppose the userchanges the value in cell B2 of table 602 from $300 to $400. As a resultof this change, table 602 is updated to reflect the new value $400 andthe total amount in cell B6 is updated from $3,060 to $3,160. The valuein cell B2 of table 606 is updated to $2,400, causing the total amountin cell B4 in table 606 to be changed from $7,800 to $7,900.Additionally, the total amount in free floating field 608 is updatedfrom $12,060 to $12,160. All of the updating throughout the tables andfree floating fields is performed automatically in response to theuser's change of a single cell in a single table.

It is further noted that a free floating field may reference anotherfree floating field. For instance, another free floating field may beadded in document 600 to reference the first free floating field 608, ora combination of the free floating field 608 and a table cell in tables602, 604, and 606.

Nesting

The architecture 100 supports tables and free floating fields nestedwithin one another. FIG. 5 illustrates a situation in which an innertable 504 is nested within a cell B3 of outer table 502. The two tablesare independently managed and each has its own underlying pair of gridobject 130 and spreadsheet objects 106. In this example, cell C3 inouter table 502 is referencing an array of cells B1:B3 in inner table504, as represented by the summation formula in formula edit box 506.Notice that the reference syntax “Table2!B1” in the formula edit boxrefers to a separate table and not to cell B3. This is essentially thesame cross-table reference edit operation described above, even thoughthe reference is to a table nested within another table cell.

Similarly, a free floating field may be nested within a table cell, or,vice versa, a table may be nested within a free floating field. Inaddition, one or more free floating fields may be nested within one ormore other free floating fields. Essentially, the architecture and UIsupports any nesting arrangement involving tables and free floatingfields.

The nesting architecture is another feature that is an improvement overconventional table and spreadsheet approaches. OLE mechanisms ofembedding a spreadsheet object within a word processing document do notsupport nested tables.

Common Document Behaviors

The architecture allows common document behaviors for the text body andacross the tables. Such functions as spell checking, grammar checking,find, and replace are continuous across table and free floating fieldboundaries, treating the cell and free floating field contents as ifthey were part of the document. Moreover, text formatting carries acrossboundaries. Essentially, any features that are added to modify the textcan similarly be applied across a table boundary or free floating fieldto text inside a table or free floating field. The conventional OLEmechanisms of embedding a spreadsheet object within a word processingdocument were incapable of supporting these common document behaviorsthat traversed table boundaries.

The benefits of this feature are especially apparent for free floatingfields. If a user selects an entire paragraph containing several freefloating fields, the user can format the paragraph. The formatting willapply to the normal text as well as to all of the free floating fieldswithin the paragraph.

Functionality Features

This section describes how the architecture functionally supports theuser interface features described above, including recalculation,reference edit mechanics, cross-table referencing, the formula edit box,and structure changes to the table. These functionality features aredescribed separately below.

Data v. Presentation

The architecture 100 separates data functions from presentationfunctions of the integrated table/spreadsheet by employing dual objectsper table or free floating field. As shown in FIG. 3, there is one pairof spreadsheet and grid objects for each table or floating field. Thegrid object 130 maintains the data and format information, andfacilitates the recalculation process. The corresponding spreadsheetobjects 106 and free floating field objects 107 are more concerned withpresenting the table and free floating field as part of the document, aswell as capturing user inputs into the table and free floating field.

The separation is beneficial because it allows the architecture tosupport cross-table referencing, reference editing to other tables, anduniversal recalculation throughout the document. The underlying gridobjects do not care how the tables or free floating fields are laid outor where they appear in the document, nor do they care if there are oneor multiple grid objects. Similarly, the spreadsheet objects 106 andfree floating field objects 107 do not worry about the data andformulas, or the recalculation process.

Recalculation

Recalculation is a function performed by the architecture 100 inresponse to modification of a table or free floating field. When amodification is made, the architecture 100 recalculates the variousformulas in all tables and free floating fields in the document that mayhave been affected by user input.

Continuing the example of FIG. 6, when the user changes the value incell B2 of first table 602 from $300 to $400, the recalculation engine142 in spreadsheet engine 112 recalculates the formulas in cell B6 offirst table 602 to update the amount from $3,060 to $3,160. Therecalculation engine 142 also re-computes the formula in cell B2 ofthird table 606 to yield $2,400 and the formula in cell B4 in thirdtable 606 to yield $7,900. Finally, the recalculation engine 142recalculates the formula in free floating field 608 to update the valuefrom $12,060 to $12,160. This recalculation occurs automatically acrossthe entire document in response to the user input.

FIG. 9 illustrates the recalculation process 900 for a single table inmore detail. An input version of the user interface table 902(1) isshown at a time when the user enters a new value “7” in cell A1, but hasnot yet confirmed the entry (e.g., by hitting the “Enter” key orclicking out of the cell). An output version of the UI table 902(2) isshown at a time just after user confirmation.

A corresponding pair of spreadsheet and grid objects 106 and 130 existsfor the table 902. The grid object 130 maintains a cell table 134 and aformat table 132. Prior to user entry of “7” into cell A1, cell table134 contains a value “1” in cell A3, a formula referencing cell A1(i.e., “=A1”) in cell C1, and a formula summing cells A1 and C1 (i.e.,“=A1+C1”) in cell C3. The format table 132 indicates that cell A3 isformatted as a number, and that cells C1 and C3 are formatted ascurrency in U.S. dollars. The input version of UI table 902(1) showsresults of the formatted formulas as $0.00 in cell C1 and $1.00 in cellC3. Now, suppose the user enters the value “7” into cell A1 of UI table902(1), as indicated by the pointer 904. The value is received at thespreadsheet objects 106, as indicated by flow arrow 910. Once the userconfirms this entry by moving the selection out of the cell A1, thenewly entered value “7” is passed to the spreadsheet engine 112 andparticularly, the parser 144 of formula manager 140 (flow arrow 912).

The parser 144 parses the entry and determines it to be a data value.The parser 144 puts the data value into cell A1 of the cell table 134(flow arrow 914). This insertion causes a table change event, which issent to the recalculation engine 142 to initiate a recalculation (flowarrow 916). The recalculation engine 142 runs through the formula chainto recalculate any formula anywhere that is affected by the new datavalue in cell A1. In this case, the formulas in cells C1 and C3 areaffected and hence, these formulas are recalculated (flow arrow 918).The recalculation produces a result of “7” in cell C1 and a result of“8” in cell C3.

Afterwards, the format table 132 is consulted to determine the desiredformat for the new value and recalculated formulas (flow arrow 920).Here, the formula results are formatted as currency as indicated by the“$” symbols in cells C1 and C3, and the new value “7” is formatted as anumber as indicated by the “#” symbol in cell A1.

The spreadsheet engine returns the formatted results $7.00, $8.00, and 7to the spreadsheet objects 106 (flow arrow 922). The spreadsheet objects106 updates the table with these formatted results to produce the outputversion of the UI table 902(2) (flow arrow 924).

The recalculation event is essentially instantaneous. The user merelysees an immediate change in the UI table from input version 902(1) tooutput version 902(2).

The above example of recalculation was described in the context oftables. However, it is noted that essentially the same recalculationoperations may be performed in free floating fields, as is describedbelow in more detail.

Reference Edit Mechanics

The reference edit mechanism allows the user to reference another cellto obtain data, rather than forcing the user to type in a value or thereference syntax. In FIG. 9, consider the situation when the usercreated the formula “=A1” in cell C1. The user selects cell C1, types inan “=” sign to indicate a formula, and then references the cell A1 bymoving the mouse pointer 904 to cell A1 and clicking. The spreadsheetobjects 106 (namely, CellEditing object 152) capture this reference andpass it to parser 144. The parser 144 recognizes it as a formula,creates a formula object and inserts the formula into a cell of celltable 134, as indicated by cell C1. Again, a similar mechanism may beused for free floating fields.

Cross-Table and Field Referencing and Universal Recalculation

With architecture 100, reference editing may be extended across multipletables and free floating fields distributed throughout a document. Acell in one table or a free floating field may reference a cell inanother table, a different free floating field, or a combination of atable cell and free floating field. The architecture 100 automaticallyrecalculates all tables and free floating fields that are affected by achange in any one table cell or free floating field.

FIG. 10 illustrates the recalculation process 1000 for a document 1002containing multiple tables 1004(1), . . . , 1004(N) and multiple freefloating fields 1006(1), . . . , 1006(M) distributed throughout the textbody. A corresponding set of spreadsheet, free floating field, gridobjects 106, 107 and 130 is created for each table 1004(1)-1004(N) andeach free floating field 1006(1) 1006(M) in the document 1002.

In this illustration, spreadsheet object 106(1) and associated gridobject 130(1) support UI table 1004(1), spreadsheet object 106(N) andassociated grid object 130(N) support UI table 1004(N), free floatingfield object 107(1) and associated grid object 130(N+1) support freefloating field 1006(1), and free floating field object 107(M) andassociated grid object 130(N+M) support free floating field 1006(M). Thetable grid objects 130(1)-130(N) each contain a cell table 134(1)-134(N)and a format table 132(1)-132(N). The FFF grid objects 130(N+1)-130(N+M)each contain a single cell 136(1)-136(M) and a corresponding format cell138(1)-138(M).

Suppose the user is entering a summation formula in cell B1 of UI table1004(N) that adds three cells C1-C3 in table 1004(1). Rather than typingin the reference syntax (i.e., “=SUM(Table1!C1:Table1!C3)”), the usermay simply move the pointer 1010 to table 1004(1) and select the desiredarray of cells, as indicated by the selection block 1012. Thespreadsheet object 106(N) (namely, the CellEditing object) associatedwith the source table 1004(N) recognizes the reference edit operationand captures the selected cells C1-C3 in remote referenced table 1 (flowarrow 1020). When the user confirms this entry by moving the selectionout of the referenced table 1004(1), the newly entered formula“=SUM(Table1!C1:Table1!C3)” is passed to the spreadsheet engine 112 andparticularly, the parser 144 of formula manager 140 (flow arrow 1022).

The parser 144 determines that the entry is a formula and creates aformula object (not shown) and adds the formula to the formula chain.The parser 144 puts the formula into cell B1 of the cell table 134(N) incell table N (flow arrow 1024). This insertion generates a table changeevent, which is sent to the recalculation engine 142 to initiate arecalculation (flow arrow 1026).

The recalculation engine 142 runs through the entire formula chain torecalculate any formula in any table or free floating field that isaffected by adding the new formula in cell B1. In this case, theformulas in free floating cells 136(1) and 136(M) are affected. But,since these formulas rely on the result of the newly entered formula intable N, they are moved to the end of the formula chain. Thus, the newformula is first calculated (flow arrow 1028), and then the formulas infree floating field cells 136(1) and 136(M) are recalculated (flowarrows 1030 and 1032). The recalculation produces a result of “425” fortable cell B1 in cell table N, a result of “425” in FFF cell 136(1), anda result of “425” in FFF cell 136(M).

Afterwards, the various format tables 132(N) and format cells 138(1) and138(M) are consulted to determine the desired format for the results ofthe recalculated formulas. Here, all formula results are formatted ascurrency as indicated by the “$”. The spreadsheet engine 112 returns theformatted results “$425.00” to the associated spreadsheet objects106(N), 107(1), and 107(M) (flow arrows 1034, 1036, 1038). Thespreadsheet objects then update their associated table and free floatingfields with these formatted results to produce the output as shown inFIG. 10 (flow arrows 1040, 1042, 1044).

Once again, the recalculation event is essentially instantaneous and theuser merely perceives an immediate change in the affected UI table andfree floating fields throughout the document 1002.

Formula Edit Box

The CellEditing objects 152 and 162 manage the formula edit box thatpermits user edits of formulas in table cells and free floating fields.The formula edit box is provided in the user interface in response tothe user entering the “=” symbol at the beginning of a cell. The formulaedit box is overlaid as a separate entry field above the cell or freefloating field into which the user is inserting a formula. TheCellEditing object 152 or 162 captures the user entry of variousvariants in the formula, and facilitates reference editing to othercells or free floating fields as a way to input values. When the formulais entered via the formula edit box and confirmed, the CellEditingobject 152 or 162 passes the formula to the formula manager 140 in thespreadsheet engine 112 for parsing. The formula edit box is then removedfrom the user interface.

Structural Changes

The Table object 104 manages and monitors the user input for structurechanges, such as insertion/deletion of a row, merging cells, and soforth. When the user makes a structure change, the Table object 104fires events to the GridBehavior object 150, which informs thespreadsheet engine 112, and in turn updates the cell table 134associated with the UI table.

As above, any change to the cell table causes an event that is returnedto the recalculation engine 142 to initiate a recalculation cycle. Therecalculation engine steps through the chain of formulas and updates allcells affected by the structural change, returning any errors that mightarise from the structure change (e.g., loss of a reference value as aresult of deleting a row/column). The spreadsheet engine then outputsthe results of the recalculation and the UI table is updated to reflectthe structural change and the recalculation results.

Cut, Copy, Paste

A separate document object may be employed to manage operationsaffecting the entire document, rather than a specific table or freefloating field. The document object plays a role in initially insertingthe table/spreadsheet or free floating field into the document. Thedocument object may be constructed similarly to the GridBehavior object150 and configured to monitor for cut, copy, and paste operations. Whena cut or copy operation is performed, the object places the HTML code onthe clipboard. Upon a subsequent paste operation, the HTML code isretrieved from the clipboard and inserted into the appropriate location.It is noted that, unlike some spreadsheet programs, the user is notforced to cut/copy and then immediately paste.

One unique problem that is not encountered by traditional spreadsheetprograms is the ability to create a new table or free floating fieldthrough a paste operation. When a new table or free floating field iscreated, the architecture automatically renames the new table or freefloating field and adjusts all references within the table or freefloating field that was pasted.

CONCLUSION

Although the description above uses language that is specific tostructural features and/or methodological acts, it is to be understoodthat the invention defined in the appended claims is not limited to thespecific features or acts described. Rather, the specific features andacts are disclosed as exemplary forms of implementing the invention.

1. A method, at least partially implemented by a computer, comprising:presenting a free floating field in line with text; presenting a tablewithin a document written in eXtensible Markup Language (XML), the tablehaving a cell with contents, wherein the table is configured so thatwhen being edited, the table assumes an appearance consistent with aspreadsheet including column and row headers, and when not being edited,the table assumes an appearance consistent with a table, without columnand row headers; and enabling a user to reference the cell in the tablewhen entering a formula into the free floating field.
 2. The method ofclaim 1, further comprising, upon modification of the contents in thecell of the table, automatically recalculating the formula in the freefloating field.
 3. A tangible computer readable medium havingcomputer-executable instructions that, when executed on one or moreprocessors, perform the method as recited in claim
 1. 4. A method, atleast partially implemented by a computer, comprising: presenting a freefloating field in line with text from a document written in eXtensibleMarkup Language (XML); creating a cell structure to hold one of data ora formula for the free floating field; creating a format structure tohold formatting information for the free floating field; receiving, intothe free floating field, user entry of a reference to a source in thedocument or user entry of text, wherein receiving user entry comprises:alternately displaying a first user interface or a second user interfacebased upon a type of content already in the free floating field, whereinthe first and second user interfaces comprise different interfacestailored for formula editing or text editing; and interpreting contentadded to the free floating field based upon the type of the contentalready in the free floating field; parsing the user input to update thecell structure and the format structure; in an event the user inputcauses changes in the cell structure or format structure, updating thecell structure or format structure to produce a new result; andpresenting the free floating field with the new result.
 5. A tangiblecomputer readable medium having computer-executable instructions that,when executed on one or more processors, perform the method as recitedin claim
 4. 6. A method, at least partially implemented by a computer,comprising: presenting a free floating field in line with text from adocument written in eXtensible Markup Language (XML); number formattingthe free floating field independent of the text; and evaluating contentsof the free floating field to determine if the contents include aformula or text, wherein the evaluation determines how new content addedto the free floating field is interpreted and what user interface isprovided, the user interface configured according to: if the content isa formula, providing a formula editing box wherein all of the formula ishighlighted to allowing editing; and if the content is not a formula,placing a cursor in the free floating field to allow editing of thecontent of the free floating field.
 7. A tangible computer readablemedium having computer-executable instructions that, when executed onone or more processors, comprise instructions for: displaying a freefloating field in line with text from a document written in eXtensibleMarkup Language (XML), wherein content is added to the free floatingfield according to a method comprising: interpreting content added tothe free floating field based upon the type of the content already inthe free floating field; and alternately displaying a first userinterface or a second user interface based upon the type of contentalready in the free floating field, wherein the first and second userinterfaces are associated with editing a formula and editing text,respectively; creating a reference, within the free floating field, toat least one source elsewhere in the document; and upon modification ofthe source, automatically updating the free floating field.
 8. Thetangible computer readable medium of claim 7, wherein the source is textand the free floating field references the text.
 9. The tangiblecomputer readable medium of claim 7, wherein the source is a data valueand the free floating field contains a formula that references the datavalue.
 10. The tangible computer readable medium of claim 7, wherein thefree floating field is a first free floating field, and furthercomprising computer-executable instructions to: display a second freefloating field; create a reference, within the second free floatingfield, to the first free floating field; and upon modification of thesource, automatically update the first and second free floating fields.11. A tangible computer readable medium having computer-executableinstructions that, when executed on one or more processors, compriseinstructions for: presenting a free floating field in line with textfrom a document written in eXtensible Markup Language (XML); receivinguser-entered formula into the free floating field, the formulareferencing at least one data value elsewhere in the document, whereinthe receiving comprises: determining a type of content already in thefree floating field to be a formula; and in response to the contentbeing the formula, displaying a user interface appropriate to editingthe formula and distinct from a user interface appropriate for editingtext; upon modification of the data value, automatically recalculatingthe formula in the free floating field.
 12. The tangible computerreadable medium of claim 11, further comprising computer-executableinstructions to overlay a formula edit box on the free floating field tofacilitate user entry of the formula into the free floating field. 13.The tangible computer readable medium of claim 11, further comprisingcomputer-executable instructions to: present a table; and create areference from the free floating field to a cell in the table.